રિએક્ટ ફ્લાઇટનું રહસ્યોદ્ઘાટન: સર્વર કમ્પોનન્ટ્સને શક્તિ આપતો સિરિયલાઇઝેબલ પ્રોટોકોલ

વેબ ડેવલપમેન્ટની દુનિયા સતત વિકસતી રહે છે. વર્ષો સુધી, પ્રચલિત પેરાડાઈમ સિંગલ પેજ એપ્લિકેશન (SPA) હતી, જેમાં એક ન્યૂનતમ HTML શેલ ક્લાયન્ટને મોકલવામાં આવે છે, જે પછી ડેટા મેળવે છે અને જાવાસ્ક્રિપ્ટનો ઉપયોગ કરીને સમગ્ર યુઝર ઇન્ટરફેસ રેન્ડર કરે છે. આ મોડેલ શક્તિશાળી હોવા છતાં, તેણે મોટી બંડલ સાઇઝ, ક્લાયન્ટ-સર્વર ડેટા વોટરફોલ્સ અને જટિલ સ્ટેટ મેનેજમેન્ટ જેવા પડકારો રજૂ કર્યા. તેના પ્રતિભાવમાં, સમુદાય સર્વર-કેન્દ્રિત આર્કિટેક્ચર તરફ પાછા ફરવાનો એક મહત્વપૂર્ણ ફેરફાર જોઈ રહ્યો છે, પરંતુ એક આધુનિક ટ્વિસ્ટ સાથે. આ ઉત્ક્રાંતિમાં સૌથી આગળ રિએક્ટ ટીમનું એક ક્રાંતિકારી ફીચર છે: રિએક્ટ સર્વર કમ્પોનન્ટ્સ (RSC).

પરંતુ આ કમ્પોનન્ટ્સ, જે ફક્ત સર્વર પર ચાલે છે, તે જાદુઈ રીતે કેવી રીતે દેખાય છે અને ક્લાયન્ટ-સાઇડ એપ્લિકેશનમાં કેવી રીતે એકીકૃત થાય છે? જવાબ એક ઓછી જાણીતી પરંતુ અત્યંત મહત્વપૂર્ણ ટેકનોલોજીમાં રહેલો છે: રિએક્ટ ફ્લાઇટ. આ કોઈ API નથી જેનો તમે દરરોજ સીધો ઉપયોગ કરશો, પરંતુ તેને સમજવું એ આધુનિક રિએક્ટ ઇકોસિસ્ટમની સંપૂર્ણ ક્ષમતાને અનલૉક કરવાની ચાવી છે. આ પોસ્ટ તમને રિએક્ટ ફ્લાઇટ પ્રોટોકોલમાં ઊંડાણપૂર્વક લઈ જશે, જે વેબ એપ્લિકેશન્સની આગામી પેઢીને શક્તિ આપતા એન્જિનનું રહસ્યોદ્ઘાટન કરશે.

રિએક્ટ સર્વર કમ્પોનન્ટ્સ શું છે? એક ઝડપી પુનરાવર્તન

આપણે પ્રોટોકોલનું વિશ્લેષણ કરીએ તે પહેલાં, ચાલો સંક્ષિપ્તમાં જોઈએ કે રિએક્ટ સર્વર કમ્પોનન્ટ્સ શું છે અને તે શા માટે મહત્વપૂર્ણ છે. બ્રાઉઝરમાં ચાલતા પરંપરાગત રિએક્ટ કમ્પોનન્ટ્સથી વિપરીત, RSCs એ એક નવા પ્રકારનો કમ્પોનન્ટ છે જે ફક્ત સર્વર પર ચલાવવા માટે રચાયેલ છે. તેઓ તેમનો જાવાસ્ક્રિપ્ટ કોડ ક્યારેય ક્લાયન્ટને મોકલતા નથી.

આ સર્વર-ઓન્લી એક્ઝેક્યુશન ઘણા ગેમ-ચેન્જિંગ ફાયદાઓ પ્રદાન કરે છે:

• ઝીરો-બંડલ સાઇઝ: કારણ કે કમ્પોનન્ટનો કોડ ક્યારેય સર્વર છોડતો નથી, તે તમારા ક્લાયન્ટ-સાઇડ જાવાસ્ક્રિપ્ટ બંડલમાં કંઈપણ ફાળો આપતો નથી. આ પર્ફોર્મન્સ માટે એક મોટી જીત છે, ખાસ કરીને જટિલ, ડેટા-હેવી કમ્પોનન્ટ્સ માટે.
• ડાયરેક્ટ ડેટા એક્સેસ: RSCs સીધા જ સર્વર-સાઇડ સંસાધનો જેવા કે ડેટાબેઝ, ફાઇલ સિસ્ટમ્સ અથવા આંતરિક માઇક્રોસર્વિસિસને એક્સેસ કરી શકે છે, API એન્ડપોઇન્ટ એક્સપોઝ કરવાની જરૂર વગર. આ ડેટા મેળવવાની પ્રક્રિયાને સરળ બનાવે છે અને ક્લાયન્ટ-સર્વર રિક્વેસ્ટ વોટરફોલ્સને દૂર કરે છે.
• ઓટોમેટિક કોડ સ્પ્લિટિંગ: કારણ કે તમે ગતિશીલ રીતે પસંદ કરી શકો છો કે કયા કમ્પોનન્ટ્સને સર્વર પર રેન્ડર કરવા, તમને અસરકારક રીતે ઓટોમેટિક કોડ સ્પ્લિટિંગ મળે છે. ફક્ત ઇન્ટરેક્ટિવ ક્લાયન્ટ કમ્પોનન્ટ્સ માટેનો કોડ જ બ્રાઉઝરને મોકલવામાં આવે છે.

RSCs ને સર્વર-સાઇડ રેન્ડરિંગ (SSR) થી અલગ પાડવું મહત્વપૂર્ણ છે. SSR તમારી સંપૂર્ણ રિએક્ટ એપ્લિકેશનને સર્વર પર HTML સ્ટ્રિંગમાં પ્રી-રેન્ડર કરે છે. ક્લાયન્ટ આ HTML મેળવે છે, તેને પ્રદર્શિત કરે છે, અને પછી પેજને 'હાઇડ્રેટ' કરવા અને તેને ઇન્ટરેક્ટિવ બનાવવા માટે સંપૂર્ણ જાવાસ્ક્રિપ્ટ બંડલ ડાઉનલોડ કરે છે. તેનાથી વિપરીત, RSCs UI ના એક ખાસ, એબ્સ્ટ્રેક્ટ વર્ણનમાં રેન્ડર કરે છે—HTML નહીં—જે પછી ક્લાયન્ટને સ્ટ્રીમ કરવામાં આવે છે અને હાલના કમ્પોનન્ટ ટ્રી સાથે સમાધાન કરવામાં આવે છે. આ એક વધુ દાણાદાર અને કાર્યક્ષમ અપડેટ પ્રક્રિયાને મંજૂરી આપે છે.

રિએક્ટ ફ્લાઇટનો પરિચય: મુખ્ય પ્રોટોકોલ

તો, જો સર્વર કમ્પોનન્ટ HTML અથવા તેનો પોતાનો જાવાસ્ક્રિપ્ટ મોકલી રહ્યું નથી, તો તે શું મોકલી રહ્યું છે? અહીં જ રિએક્ટ ફ્લાઇટ આવે છે. રિએક્ટ ફ્લાઇટ એ એક હેતુ-નિર્મિત સિરિયલાઇઝેશન પ્રોટોકોલ છે જે રેન્ડર થયેલ રિએક્ટ કમ્પોનન્ટ ટ્રીને સર્વરથી ક્લાયન્ટ સુધી ટ્રાન્સમિટ કરવા માટે રચાયેલ છે.

તેને JSON ના એક વિશિષ્ટ, સ્ટ્રીમેબલ સંસ્કરણ તરીકે વિચારો જે રિએક્ટ પ્રિમિટિવ્સને સમજે છે. તે 'વાયર ફોર્મેટ' છે જે તમારા સર્વર પર્યાવરણ અને વપરાશકર્તાના બ્રાઉઝર વચ્ચેના અંતરને પૂરે છે. જ્યારે તમે RSC રેન્ડર કરો છો, ત્યારે રિએક્ટ HTML જનરેટ કરતું નથી. તેના બદલે, તે રિએક્ટ ફ્લાઇટ ફોર્મેટમાં ડેટાનો સ્ટ્રીમ જનરેટ કરે છે.

શા માટે ફક્ત HTML અથવા JSON નો ઉપયોગ ન કરવો?

એક સ્વાભાવિક પ્રશ્ન છે, શા માટે એક સંપૂર્ણ નવો પ્રોટોકોલ બનાવવો? આપણે હાલના ધોરણોનો ઉપયોગ કેમ ન કરી શક્યા?

• HTML શા માટે નહીં? HTML મોકલવું એ SSR નું ડોમેન છે. HTML સાથે સમસ્યા એ છે કે તે અંતિમ રજૂઆત છે. તે કમ્પોનન્ટ માળખું અને સંદર્ભ ગુમાવે છે. તમે સંપૂર્ણ પેજ રીલોડ અથવા જટિલ DOM મેનિપ્યુલેશન વિના હાલની, ઇન્ટરેક્ટિવ ક્લાયન્ટ-સાઇડ રિએક્ટ એપ્લિકેશનમાં સ્ટ્રીમ કરેલ HTML ના નવા ટુકડાઓને સરળતાથી એકીકૃત કરી શકતા નથી. રિએક્ટને જાણવાની જરૂર છે કે કયા ભાગો કમ્પોનન્ટ્સ છે, તેમના પ્રોપ્સ શું છે, અને ઇન્ટરેક્ટિવ 'ટાપુઓ' (ક્લાયન્ટ કમ્પોનન્ટ્સ) ક્યાં સ્થિત છે.
• સ્ટાન્ડર્ડ JSON શા માટે નહીં? JSON ડેટા માટે ઉત્તમ છે, પરંતુ તે UI કમ્પોનન્ટ્સ, JSX, અથવા સસ્પેન્સ બાઉન્ડ્રીઝ જેવી વિભાવનાઓને મૂળભૂત રીતે રજૂ કરી શકતું નથી. તમે કમ્પોનન્ટ ટ્રીને રજૂ કરવા માટે JSON સ્કીમા બનાવવાનો પ્રયાસ કરી શકો છો, પરંતુ તે વર્બોઝ હશે અને ક્લાયન્ટ પર ગતિશીલ રીતે લોડ અને રેન્ડર કરવાની જરૂર હોય તેવા કમ્પોનન્ટને કેવી રીતે રજૂ કરવું તેની સમસ્યાને હલ કરશે નહીં.

રિએક્ટ ફ્લાઇટ આ વિશિષ્ટ સમસ્યાઓ હલ કરવા માટે બનાવવામાં આવી હતી. તે આ માટે રચાયેલ છે:

1. સિરિયલાઇઝેબલ (Serializable): પ્રોપ્સ અને સ્ટેટ સહિત સમગ્ર કમ્પોનન્ટ ટ્રીને રજૂ કરવામાં સક્ષમ.
2. સ્ટ્રીમેબલ (Streamable): UI ને ટુકડાઓમાં મોકલી શકાય છે, જેનાથી ક્લાયન્ટ સંપૂર્ણ પ્રતિસાદ ઉપલબ્ધ થાય તે પહેલાં રેન્ડરિંગ શરૂ કરી શકે છે. આ સસ્પેન્સ સાથેના એકીકરણ માટે મૂળભૂત છે.
3. રિએક્ટ-અવેર (React-Aware): તેમાં કમ્પોનન્ટ્સ, કન્ટેક્સ્ટ અને ક્લાયન્ટ-સાઇડ કોડના લેઝી-લોડિંગ જેવી રિએક્ટ વિભાવનાઓ માટે ફર્સ્ટ-ક્લાસ સપોર્ટ છે.

રિએક્ટ ફ્લાઇટ કેવી રીતે કાર્ય કરે છે: એક સ્ટેપ-બાય-સ્ટેપ બ્રેકડાઉન

રિએક્ટ ફ્લાઇટનો ઉપયોગ કરવાની પ્રક્રિયામાં સર્વર અને ક્લાયન્ટ વચ્ચે સંકલિત નૃત્યનો સમાવેશ થાય છે. ચાલો RSCs નો ઉપયોગ કરતી એપ્લિકેશનમાં વિનંતીના જીવનચક્રમાંથી પસાર થઈએ.

સર્વર પર

1. રિક્વેસ્ટની શરૂઆત: વપરાશકર્તા તમારી એપ્લિકેશનમાં એક પેજ પર નેવિગેટ કરે છે (દા.ત., Next.js એપ રાઉટર પેજ).
2. કમ્પોનન્ટ રેન્ડરિંગ: રિએક્ટ તે પેજ માટે સર્વર કમ્પોનન્ટ ટ્રી રેન્ડર કરવાનું શરૂ કરે છે.
3. ડેટા ફેચિંગ: જેમ જેમ તે ટ્રીમાંથી પસાર થાય છે, તે ડેટા મેળવતા કમ્પોનન્ટ્સનો સામનો કરે છે (દા.ત., `async function MyServerComponent() { ... }`). તે આ ડેટા ફેચની રાહ જુએ છે.
4. ફ્લાઇટ સ્ટ્રીમમાં સિરિયલાઇઝેશન: HTML ઉત્પન્ન કરવાને બદલે, રિએક્ટ રેન્ડરર ટેક્સ્ટનો સ્ટ્રીમ જનરેટ કરે છે. આ ટેક્સ્ટ રિએક્ટ ફ્લાઇટ પેલોડ છે. કમ્પોનન્ટ ટ્રીનો દરેક ભાગ—એક `div`, એક `p`, ટેક્સ્ટની સ્ટ્રિંગ, ક્લાયન્ટ કમ્પોનન્ટનો સંદર્ભ—આ સ્ટ્રીમમાં એક વિશિષ્ટ ફોર્મેટમાં એન્કોડ થયેલ છે.
5. રિસ્પોન્સનું સ્ટ્રીમિંગ: સર્વર સંપૂર્ણ ટ્રી રેન્ડર થવાની રાહ જોતું નથી. જલદી UI ના પ્રથમ ટુકડાઓ તૈયાર થાય છે, તે HTTP પર ક્લાયન્ટને ફ્લાઇટ પેલોડ સ્ટ્રીમ કરવાનું શરૂ કરે છે. જો તે સસ્પેન્સ બાઉન્ડ્રીનો સામનો કરે છે, તો તે એક પ્લેસહોલ્ડર મોકલે છે અને પૃષ્ઠભૂમિમાં સસ્પેન્ડેડ કન્ટેન્ટનું રેન્ડરિંગ ચાલુ રાખે છે, જ્યારે તે તૈયાર થાય ત્યારે તેને તે જ સ્ટ્રીમમાં પછીથી મોકલે છે.

ક્લાયન્ટ પર

1. સ્ટ્રીમ પ્રાપ્ત કરવું: બ્રાઉઝરમાં રિએક્ટ રનટાઇમ ફ્લાઇટ સ્ટ્રીમ મેળવે છે. તે એક જ દસ્તાવેજ નથી પરંતુ સૂચનાઓનો સતત પ્રવાહ છે.
2. પાર્સિંગ અને રિકન્સિલિએશન: ક્લાયન્ટ-સાઇડ રિએક્ટ કોડ ફ્લાઇટ સ્ટ્રીમને ટુકડે ટુકડે પાર્સ કરે છે. તે UI બનાવવા અથવા અપડેટ કરવા માટે બ્લુપ્રિન્ટનો સેટ મેળવવા જેવું છે.
3. ટ્રીનું પુનર્નિર્માણ: દરેક સૂચના માટે, રિએક્ટ તેના વર્ચ્યુઅલ DOM ને અપડેટ કરે છે. તે એક નવો `div` બનાવી શકે છે, થોડો ટેક્સ્ટ દાખલ કરી શકે છે, અથવા—સૌથી અગત્યનું—ક્લાયન્ટ કમ્પોનન્ટ માટે પ્લેસહોલ્ડર ઓળખી શકે છે.
4. ક્લાયન્ટ કમ્પોનન્ટ્સ લોડ કરી રહ્યું છે: જ્યારે સ્ટ્રીમમાં ક્લાયન્ટ કમ્પોનન્ટનો સંદર્ભ હોય છે (જે "use client" નિર્દેશ સાથે ચિહ્નિત થયેલ હોય છે), ત્યારે ફ્લાઇટ પેલોડમાં કયું જાવાસ્ક્રિપ્ટ બંડલ ડાઉનલોડ કરવું તે વિશેની માહિતી શામેલ હોય છે. રિએક્ટ પછી તે બંડલ મેળવે છે જો તે પહેલાથી કેશ થયેલ ન હોય.
5. હાઇડ્રેશન અને ઇન્ટરેક્ટિવિટી: એકવાર ક્લાયન્ટ કમ્પોનન્ટનો કોડ લોડ થઈ જાય, રિએક્ટ તેને નિયુક્ત જગ્યાએ રેન્ડર કરે છે અને તેને હાઇડ્રેટ કરે છે, ઇવેન્ટ લિસનર્સ જોડે છે અને તેને સંપૂર્ણપણે ઇન્ટરેક્ટિવ બનાવે છે. આ પ્રક્રિયા અત્યંત લક્ષિત છે અને ફક્ત પેજના ઇન્ટરેક્ટિવ ભાગો માટે જ થાય છે.

આ સ્ટ્રીમિંગ અને સિલેક્ટિવ હાઇડ્રેશન મોડેલ પરંપરાગત SSR મોડેલ કરતાં ઘણું વધારે કાર્યક્ષમ છે, જેને ઘણીવાર સંપૂર્ણ પેજના "ઓલ-ઓર-નથિંગ" હાઇડ્રેશનની જરૂર પડે છે.

રિએક્ટ ફ્લાઇટ પેલોડની એનાટોમી

રિએક્ટ ફ્લાઇટને સાચા અર્થમાં સમજવા માટે, તે ઉત્પન્ન કરે છે તે ડેટાના ફોર્મેટને જોવું મદદરૂપ છે. જો કે તમે સામાન્ય રીતે આ કાચા આઉટપુટ સાથે સીધો સંપર્ક કરશો નહીં, તેની રચના જોવાથી તે કેવી રીતે કાર્ય કરે છે તે જાહેર થાય છે. પેલોડ એ ન્યૂલાઇન-સેપરેટેડ JSON-જેવા સ્ટ્રિંગ્સનો સ્ટ્રીમ છે. દરેક લાઇન, અથવા ચંક, માહિતીનો એક ભાગ રજૂ કરે છે.

ચાલો એક સરળ ઉદાહરણ ધ્યાનમાં લઈએ. કલ્પના કરો કે આપણી પાસે આના જેવો સર્વર કમ્પોનન્ટ છે:

app/page.js (સર્વર કમ્પોનન્ટ)

<!-- Assume this is a code block in a real blog --> async function Page() { const userData = await fetchUser(); // Fetches { name: 'Alice' } return ( <div> <h1>Welcome, {userData.name}</h1> <p>Here is your dashboard.</p> <InteractiveButton text="Click Me" /> </div> ); }

અને એક ક્લાયન્ટ કમ્પોનન્ટ:

components/InteractiveButton.js (ક્લાયન્ટ કમ્પોનન્ટ)

<!-- Assume this is a code block in a real blog --> 'use client'; import { useState } from 'react'; export default function InteractiveButton({ text }) { const [count, setCount] = useState(0); return ( <button onClick={() => setCount(count + 1)}> {text} ({count}) </button> ); }

સર્વરથી ક્લાયન્ટને આ UI માટે મોકલવામાં આવેલ રિએક્ટ ફ્લાઇટ સ્ટ્રીમ કંઈક આના જેવો દેખાઈ શકે છે (સ્પષ્ટતા માટે સરળ બનાવેલ):

<!-- Simplified example of a Flight stream --> M1:{"id":"./components/InteractiveButton.js","chunks":["chunk-abcde.js"],"name":"default"} J0:["$","div",null,{"children":[["$","h1",null,{"children":["Welcome, ","Alice"]}],["$","p",null,{"children":"Here is your dashboard."}],["$","@1",null,{"text":"Click Me"}]]}]

ચાલો આ ગુપ્ત આઉટપુટનું વિશ્લેષણ કરીએ:

• `M` પંક્તિઓ (મોડ્યુલ મેટાડેટા): `M1:` થી શરૂ થતી લાઇન એ મોડ્યુલ સંદર્ભ છે. તે ક્લાયન્ટને કહે છે: "`@1` ID દ્વારા સંદર્ભિત કમ્પોનન્ટ `./components/InteractiveButton.js` ફાઇલમાંથી ડિફોલ્ટ એક્સપોર્ટ છે. તેને લોડ કરવા માટે, તમારે `chunk-abcde.js` જાવાસ્ક્રિપ્ટ ફાઇલ ડાઉનલોડ કરવાની જરૂર છે." આ રીતે ડાયનેમિક ઇમ્પોર્ટ્સ અને કોડ સ્પ્લિટિંગ હેન્ડલ થાય છે.
• `J` પંક્તિઓ (JSON ડેટા): `J0:` થી શરૂ થતી લાઇનમાં સિરિયલાઇઝ્ડ કમ્પોનન્ટ ટ્રી છે. ચાલો તેની રચના જોઈએ: `["$","div",null,{...}]`.
• `$` પ્રતીક: આ એક વિશિષ્ટ ઓળખકર્તા છે જે રિએક્ટ એલિમેન્ટ (મૂળભૂત રીતે, JSX) સૂચવે છે. ફોર્મેટ સામાન્ય રીતે `["$", type, key, props]` હોય છે.
• કમ્પોનન્ટ ટ્રી સ્ટ્રક્ચર: તમે HTML ની નેસ્ટેડ રચના જોઈ શકો છો. `div` પાસે `children` પ્રોપ છે, જે `h1`, `p`, અને અન્ય રિએક્ટ એલિમેન્ટ ધરાવતો એરે છે.
• ડેટા ઇન્ટિગ્રેશન: નોંધ લો કે નામ `"Alice"` સીધું સ્ટ્રીમમાં એમ્બેડ થયેલું છે. સર્વરના ડેટા ફેચનું પરિણામ સીધું UI વર્ણનમાં સિરિયલાઇઝ્ડ છે. ક્લાયન્ટને જાણવાની જરૂર નથી કે આ ડેટા કેવી રીતે મેળવવામાં આવ્યો હતો.
• `@` પ્રતીક (ક્લાયન્ટ કમ્પોનન્ટ સંદર્ભ): સૌથી રસપ્રદ ભાગ `["$","@1",null,{"text":"Click Me"}]` છે. `@1` એ એક સંદર્ભ છે. તે ક્લાયન્ટને કહે છે: "ટ્રીમાં આ જગ્યાએ, તમારે મોડ્યુલ મેટાડેટા `M1` દ્વારા વર્ણવેલ ક્લાયન્ટ કમ્પોનન્ટને રેન્ડર કરવાની જરૂર છે. અને જ્યારે તમે તેને રેન્ડર કરો, ત્યારે તેને આ પ્રોપ્સ પાસ કરો: `{ text: 'Click Me' }`."

આ પેલોડ સૂચનાઓનો સંપૂર્ણ સેટ છે. તે ક્લાયન્ટને બરાબર કહે છે કે UI કેવી રીતે બનાવવું, કઈ સ્ટેટિક કન્ટેન્ટ પ્રદર્શિત કરવી, ઇન્ટરેક્ટિવ કમ્પોનન્ટ્સ ક્યાં મૂકવા, તેમના કોડને કેવી રીતે લોડ કરવો, અને તેમને કયા પ્રોપ્સ પાસ કરવા. આ બધું કોમ્પેક્ટ, સ્ટ્રીમેબલ ફોર્મેટમાં કરવામાં આવે છે.

રિએક્ટ ફ્લાઇટ પ્રોટોકોલના મુખ્ય ફાયદા

ફ્લાઇટ પ્રોટોકોલની ડિઝાઇન સીધી રીતે RSC પેરાડાઈમના મુખ્ય લાભોને સક્ષમ કરે છે. પ્રોટોકોલને સમજવાથી તે સ્પષ્ટ થાય છે કે આ ફાયદા શા માટે શક્ય છે.

સ્ટ્રીમિંગ અને નેટિવ સસ્પેન્સ

કારણ કે પ્રોટોકોલ ન્યૂલાઇન-ડેલિમિટેડ સ્ટ્રીમ છે, સર્વર UI ને રેન્ડર થતાં જ મોકલી શકે છે. જો કોઈ કમ્પોનન્ટ સસ્પેન્ડ થયેલ હોય (દા.ત., ડેટાની રાહ જોતું હોય), તો સર્વર સ્ટ્રીમમાં એક પ્લેસહોલ્ડર સૂચના મોકલી શકે છે, પેજના બાકીના UI ને મોકલી શકે છે, અને પછી, એકવાર ડેટા તૈયાર થઈ જાય, ત્યારે પ્લેસહોલ્ડરને વાસ્તવિક કન્ટેન્ટ સાથે બદલવા માટે તે જ સ્ટ્રીમમાં નવી સૂચના મોકલી શકે છે. આ જટિલ ક્લાયન્ટ-સાઇડ લોજિક વિના ફર્સ્ટ-ક્લાસ સ્ટ્રીમિંગ અનુભવ પ્રદાન કરે છે.

સર્વર લોજિક માટે ઝીરો-બંડલ સાઇઝ

પેલોડને જોતાં, તમે જોઈ શકો છો કે `Page` કમ્પોનન્ટમાંથી કોઈ કોડ હાજર નથી. ડેટા ફેચિંગ લોજિક, કોઈપણ જટિલ બિઝનેસ ગણતરીઓ, અથવા ફક્ત સર્વર પર વપરાતી મોટી લાઇબ્રેરીઓ જેવી અવલંબન સંપૂર્ણપણે ગેરહાજર છે. સ્ટ્રીમમાં ફક્ત તે લોજિકનું *આઉટપુટ* હોય છે. આ RSCs ના "ઝીરો-બંડલ સાઇઝ" વચનની પાછળની મૂળભૂત પદ્ધતિ છે.

ડેટા ફેચિંગનું કોલોકેશન

`userData` ફેચ સર્વર પર થાય છે, અને ફક્ત તેનું પરિણામ (`'Alice'`) સ્ટ્રીમમાં સિરિયલાઇઝ્ડ થાય છે. આ વિકાસકર્તાઓને જે કમ્પોનન્ટને તેની જરૂર હોય તેની અંદર જ ડેટા-ફેચિંગ કોડ લખવાની મંજૂરી આપે છે, આ ખ્યાલને કોલોકેશન તરીકે ઓળખવામાં આવે છે. આ પેટર્ન કોડને સરળ બનાવે છે, જાળવણીક્ષમતા સુધારે છે, અને ઘણી SPAs ને પીડતા ક્લાયન્ટ-સર્વર વોટરફોલ્સને દૂર કરે છે.

સિલેક્ટિવ હાઇડ્રેશન

રેન્ડર કરેલ HTML એલિમેન્ટ્સ અને ક્લાયન્ટ કમ્પોનન્ટ સંદર્ભો (`@`) વચ્ચે પ્રોટોકોલનો સ્પષ્ટ ભેદ એ છે જે સિલેક્ટિવ હાઇડ્રેશનને સક્ષમ કરે છે. ક્લાયન્ટ-સાઇડ રિએક્ટ રનટાઇમ જાણે છે કે ફક્ત `@` કમ્પોનન્ટ્સને જ ઇન્ટરેક્ટિવ બનવા માટે તેમના સંબંધિત જાવાસ્ક્રિપ્ટની જરૂર છે. તે ટ્રીના સ્ટેટિક ભાગોને અવગણી શકે છે, પ્રારંભિક પેજ લોડ પર નોંધપાત્ર ગણતરીના સંસાધનો બચાવે છે.

રિએક્ટ ફ્લાઇટ વિ. વિકલ્પો: એક વૈશ્વિક પરિપ્રેક્ષ્ય

રિએક્ટ ફ્લાઇટની નવીનતાની પ્રશંસા કરવા માટે, તેને વૈશ્વિક વેબ ડેવલપમેન્ટ સમુદાયમાં વપરાતા અન્ય અભિગમો સાથે સરખાવવું મદદરૂપ છે.

વિ. પરંપરાગત SSR + હાઇડ્રેશન

ઉલ્લેખ કર્યો છે તેમ, પરંપરાગત SSR સંપૂર્ણ HTML દસ્તાવેજ મોકલે છે. ક્લાયન્ટ પછી એક મોટું જાવાસ્ક્રિપ્ટ બંડલ ડાઉનલોડ કરે છે અને સમગ્ર દસ્તાવેજને "હાઇડ્રેટ" કરે છે, સ્ટેટિક HTML સાથે ઇવેન્ટ લિસનર્સ જોડે છે. આ ધીમું અને નાજુક હોઈ શકે છે. એક જ ભૂલ સમગ્ર પેજને ઇન્ટરેક્ટિવ બનતા અટકાવી શકે છે. રિએક્ટ ફ્લાઇટની સ્ટ્રીમેબલ અને સિલેક્ટિવ પ્રકૃતિ આ ખ્યાલનો વધુ સ્થિતિસ્થાપક અને કાર્યક્ષમ વિકાસ છે.

વિ. GraphQL/REST APIs

એક સામાન્ય મૂંઝવણ એ છે કે શું RSCs GraphQL અથવા REST જેવા ડેટા APIs ને બદલે છે. જવાબ ના છે; તેઓ પૂરક છે. રિએક્ટ ફ્લાઇટ એ UI ટ્રીને સિરિયલાઇઝ્ડ કરવા માટેનો પ્રોટોકોલ છે, સામાન્ય-હેતુ ડેટા ક્વેરી ભાષા નથી. હકીકતમાં, સર્વર કમ્પોનન્ટ ઘણીવાર સર્વર પર GraphQL અથવા REST API નો ઉપયોગ તેના ડેટાને રેન્ડરિંગ પહેલાં મેળવવા માટે કરશે. મુખ્ય તફાવત એ છે કે આ API કોલ સર્વર-ટુ-સર્વર થાય છે, જે સામાન્ય રીતે ક્લાયન્ટ-ટુ-સર્વર કોલ કરતાં ઘણું ઝડપી અને વધુ સુરક્ષિત હોય છે. ક્લાયન્ટ ફ્લાઇટ સ્ટ્રીમ દ્વારા અંતિમ UI મેળવે છે, કાચો ડેટા નહીં.

વિ. અન્ય આધુનિક ફ્રેમવર્ક

વૈશ્વિક ઇકોસિસ્ટમમાં અન્ય ફ્રેમવર્ક પણ સર્વર-ક્લાયન્ટ વિભાજનનો સામનો કરી રહ્યા છે. ઉદાહરણ તરીકે:

• એસ્ટ્રો આઇલેન્ડ્સ (Astro Islands): એસ્ટ્રો સમાન 'આઇલેન્ડ' આર્કિટેક્ચરનો ઉપયોગ કરે છે, જ્યાં મોટાભાગની સાઇટ સ્ટેટિક HTML હોય છે અને ઇન્ટરેક્ટિવ કમ્પોનન્ટ્સ વ્યક્તિગત રીતે લોડ થાય છે. આ ખ્યાલ RSC વિશ્વમાં ક્લાયન્ટ કમ્પોનન્ટ્સ જેવો જ છે. જોકે, એસ્ટ્રો મુખ્યત્વે HTML મોકલે છે, જ્યારે રિએક્ટ ફ્લાઇટ દ્વારા UI નું માળખાગત વર્ણન મોકલે છે, જે ક્લાયન્ટ-સાઇડ રિએક્ટ સ્ટેટ સાથે વધુ સીમલેસ એકીકરણને મંજૂરી આપે છે.
• ક્વિક અને રિઝ્યુમેબિલિટી (Qwik and Resumability): ક્વિક રિઝ્યુમેબિલિટી નામનો એક અલગ અભિગમ અપનાવે છે. તે એપ્લિકેશનની સંપૂર્ણ સ્થિતિને HTML માં સિરિયલાઇઝ્ડ કરે છે, તેથી ક્લાયન્ટને સ્ટાર્ટઅપ પર કોડ ફરીથી ચલાવવાની જરૂર નથી (હાઇડ્રેશન). તે જ્યાં સર્વર છોડી ગયું હતું ત્યાંથી 'ફરી શરૂ' કરી શકે છે. રિએક્ટ ફ્લાઇટ અને સિલેક્ટિવ હાઇડ્રેશનનો હેતુ સમાન ફાસ્ટ-ટાઇમ-ટુ-ઇન્ટરેક્ટિવ ધ્યેય પ્રાપ્ત કરવાનો છે, પરંતુ ફક્ત જરૂરી ઇન્ટરેક્ટિવ કોડ લોડ કરીને અને ચલાવીને એક અલગ પદ્ધતિ દ્વારા.

વિકાસકર્તાઓ માટે વ્યવહારુ અસરો અને શ્રેષ્ઠ પ્રયાસો

જો કે તમે રિએક્ટ ફ્લાઇટ પેલોડ્સ હાથથી લખશો નહીં, પ્રોટોકોલને સમજવું એ તમને આધુનિક રિએક્ટ એપ્લિકેશન્સ કેવી રીતે બનાવવી જોઈએ તે સૂચવે છે.

`"use server"` અને `"use client"` અપનાવો

Next.js જેવા ફ્રેમવર્કમાં, `"use client"` નિર્દેશ એ સર્વર અને ક્લાયન્ટ વચ્ચેની સીમાને નિયંત્રિત કરવા માટેનું તમારું પ્રાથમિક સાધન છે. તે બિલ્ડ સિસ્ટમને સંકેત છે કે કમ્પોનન્ટ અને તેના બાળકોને ઇન્ટરેક્ટિવ આઇલેન્ડ તરીકે ગણવામાં આવવા જોઈએ. તેનો કોડ બંડલ કરીને બ્રાઉઝરને મોકલવામાં આવશે, અને રિએક્ટ ફ્લાઇટ તેનો સંદર્ભ સિરિયલાઇઝ્ડ કરશે. તેનાથી વિપરીત, આ નિર્દેશની ગેરહાજરી (અથવા સર્વર ક્રિયાઓ માટે `"use server"` નો ઉપયોગ) કમ્પોનન્ટ્સને સર્વર પર રાખે છે. કાર્યક્ષમ એપ્લિકેશન્સ બનાવવા માટે આ સીમામાં નિપુણતા મેળવો.

કમ્પોનન્ટ્સમાં વિચારો, એન્ડપોઇન્ટ્સમાં નહીં

RSCs સાથે, કમ્પોનન્ટ પોતે જ ડેટા કન્ટેનર હોઈ શકે છે. `/api/user` એપીઆઈ એન્ડપોઇન્ટ બનાવવા અને ક્લાયન્ટ-સાઇડ કમ્પોનન્ટ જે તેમાંથી ડેટા મેળવે છે તેના બદલે, તમે એક જ સર્વર કમ્પોનન્ટ `` બનાવી શકો છો જે આંતરિક રીતે ડેટા મેળવે છે. આ આર્કિટેક્ચરને સરળ બનાવે છે અને વિકાસકર્તાઓને UI અને તેના ડેટાને એક જ, સુસંગત એકમ તરીકે વિચારવા માટે પ્રોત્સાહિત કરે છે.

સુરક્ષા એ સર્વર-સાઇડની ચિંતા છે

કારણ કે RSCs સર્વર કોડ છે, તેમની પાસે સર્વર વિશેષાધિકારો છે. આ શક્તિશાળી છે પરંતુ સુરક્ષા માટે શિસ્તબદ્ધ અભિગમની જરૂર છે. તમામ ડેટા એક્સેસ, પર્યાવરણ ચલનો ઉપયોગ, અને આંતરિક સેવાઓ સાથેની ક્રિયાપ્રતિક્રિયાઓ અહીં થાય છે. આ કોડને તે જ કડકતા સાથે વર્તો જે તમે કોઈપણ બેકએન્ડ API સાથે કરશો: તમામ ઇનપુટ્સને સેનિટાઇઝ કરો, ડેટાબેઝ ક્વેરીઝ માટે તૈયાર સ્ટેટમેન્ટ્સનો ઉપયોગ કરો, અને ક્યારેય સંવેદનશીલ કીઓ અથવા રહસ્યોને એક્સપોઝ ન કરો જે ફ્લાઇટ પેલોડમાં સિરિયલાઇઝ્ડ થઈ શકે.

નવા સ્ટેકને ડિબગ કરવું

RSC વિશ્વમાં ડિબગિંગ બદલાય છે. UI બગ સર્વર-સાઇડ રેન્ડરિંગ લોજિક અથવા ક્લાયન્ટ-સાઇડ હાઇડ્રેશનમાંથી ઉદ્ભવી શકે છે. તમારે તમારા સર્વર લોગ્સ (RSCs માટે) અને બ્રાઉઝરના ડેવલપર કન્સોલ (ક્લાયન્ટ કમ્પોનન્ટ્સ માટે) બંને તપાસવામાં આરામદાયક રહેવાની જરૂર પડશે. નેટવર્ક ટેબ પણ પહેલા કરતાં વધુ મહત્વપૂર્ણ છે. તમે કાચા ફ્લાઇટ રિસ્પોન્સ સ્ટ્રીમનું નિરીક્ષણ કરી શકો છો તે જોવા માટે કે સર્વર ક્લાયન્ટને બરાબર શું મોકલી રહ્યું છે, જે મુશ્કેલીનિવારણ માટે અમૂલ્ય હોઈ શકે છે.

રિએક્ટ ફ્લાઇટ સાથે વેબ ડેવલપમેન્ટનું ભવિષ્ય

રિએક્ટ ફ્લાઇટ અને તે સક્ષમ કરે છે તે સર્વર કમ્પોનન્ટ્સ આર્કિટેક્ચર એ આપણે વેબ માટે કેવી રીતે નિર્માણ કરીએ છીએ તેની મૂળભૂત પુનર્વિચારણા રજૂ કરે છે. આ મોડેલ બંને વિશ્વના શ્રેષ્ઠને જોડે છે: કમ્પોનન્ટ-આધારિત UI ડેવલપમેન્ટનો સરળ, શક્તિશાળી વિકાસકર્તા અનુભવ અને પરંપરાગત સર્વર-રેન્ડર્ડ એપ્લિકેશન્સનું પર્ફોર્મન્સ અને સુરક્ષા.

જેમ જેમ આ ટેકનોલોજી પરિપક્વ થશે, તેમ આપણે વધુ શક્તિશાળી પેટર્ન ઉભરવાની અપેક્ષા રાખી શકીએ છીએ. સર્વર એક્શન્સ, જે ક્લાયન્ટ કમ્પોનન્ટ્સને સર્વર પર સુરક્ષિત કાર્યોને આમંત્રિત કરવાની મંજૂરી આપે છે, તે આ સર્વર-ક્લાયન્ટ કમ્યુનિકેશન ચેનલની ટોચ પર બનેલા ફીચરનું મુખ્ય ઉદાહરણ છે. પ્રોટોકોલ વિસ્તૃત કરી શકાય તેવો છે, જેનો અર્થ છે કે રિએક્ટ ટીમ ભવિષ્યમાં મુખ્ય મોડેલને તોડ્યા વિના નવી ક્ષમતાઓ ઉમેરી શકે છે.

નિષ્કર્ષ

રિએક્ટ ફ્લાઇટ એ રિએક્ટ સર્વર કમ્પોનન્ટ્સ પેરાડાઈમની અદ્રશ્ય છતાં અનિવાર્ય કરોડરજ્જુ છે. તે એક અત્યંત વિશિષ્ટ, કાર્યક્ષમ અને સ્ટ્રીમેબલ પ્રોટોકોલ છે જે સર્વર-રેન્ડર્ડ કમ્પોનન્ટ ટ્રીને સૂચનાઓના સેટમાં અનુવાદિત કરે છે જેને ક્લાયન્ટ-સાઇડ રિએક્ટ એપ્લિકેશન સમજી શકે છે અને સમૃદ્ધ, ઇન્ટરેક્ટિવ યુઝર ઇન્ટરફેસ બનાવવા માટે ઉપયોગ કરી શકે છે. કમ્પોનન્ટ્સ અને તેમની મોંઘી અવલંબનને ક્લાયન્ટ પરથી સર્વર પર ખસેડીને, તે ઝડપી, હળવા અને વધુ શક્તિશાળી વેબ એપ્લિકેશન્સને સક્ષમ કરે છે.

વિશ્વભરના વિકાસકર્તાઓ માટે, રિએક્ટ ફ્લાઇટ શું છે અને તે કેવી રીતે કાર્ય કરે છે તે સમજવું માત્ર એક શૈક્ષણિક કવાયત નથી. તે સર્વર-ડ્રાઇવન UIs ના આ નવા યુગમાં એપ્લિકેશન્સની રચના, પર્ફોર્મન્સ ટ્રેડ-ઓફ્સ બનાવવા અને સમસ્યાઓનું નિવારણ કરવા માટે એક નિર્ણાયક માનસિક મોડેલ પ્રદાન કરે છે. પરિવર્તન ચાલી રહ્યું છે, અને રિએક્ટ ફ્લાઇટ એ આગળનો માર્ગ મોકળો કરતો પ્રોટોકોલ છે.